1. The Field of the Invention
The present invention relates to secure data communication over a computer network. More specifically, the present invention relates to methods, systems, and computer program products for negotiating a secure end-to-end connection using a proxy server as an intermediary.
2. Background and Related Art
Data security over computer networks generally involves two separate considerations: (i) controlling access to the data source or server and (ii) insuring that the data is not intercepted or altered as the data travels through the network. For small private networks, data interception and/or alteration are of minimal concern because the networks are easily secured in a physical sense. For example, it is unlikely that an unauthorized person would be able to enter a home, make a connection to a computer network linking two personal computers, and intercept data exchanged between the two computers, all without being detected by the homeowner. In contrast, data transmitted over a public network, such as the Internet, may be intercepted and/or altered with relatively minor efforts. Due to the world-wide distances covered by the Internet and the virtually innumerable points of access, an unauthorized person could monitor various transactions between two computers and never be detected.
As a result, encryption techniques have been developed to insure that data exchanged over insecure networks may not be altered or deciphered in the event it is intercepted. One common technique is the use of asymmetric public/private key pairs. Only the private key is able to decrypt data encrypted with the public key and only the public key is able to decrypt data encrypted with the private key. Using the public and private keys, two computers generate secret symmetric encryption keys that are then used to encode any data exchanged between the computers. If an eavesdropper intercepts the data as it moves between computers, the information remains confidential because the eavesdropper does not know what the symmetric encryption keys are and is therefore unable to decrypt any intercepted data.
However, protecting data as it travels through a network only solves one of the problems identified above. Access to the data source or server also must be protected. Otherwise, even though intercepted data does not expose confidential information, a potential intruder simply may access the data source directly. Usernames and passwords are well-known tools for limiting access to data sources.
When one computer accesses another computer directly, the security measures described above are relatively straightforward. After establishing a secure connection to encrypt any data exchanged between the computers, usernames and passwords may be transmitted without concern because if they are intercepted, an eavesdropper will only see them in an encrypted form and will be unable to decipher them. However, the use of proxy servers requiring indirect connections between computers complicates the implementation of these security measures.
As an example, consider the authentication offered by the hypertext transfer protocol (“HTTP”). HTTP provides for authentication of a client computer to both proxy servers (“proxies”) and Web servers (“servers”) or data sources. Using authenticate challenges, proxies and servers are able to obtain credentials from client computers to insure that the client computers are authorized to use their resources. Authentication protects against unauthorized access, but, as explained above, unauthorized access is only one part of the problem. Without encryption, an eavesdropper may intercept a client's credentials and use them to gain direct access to a server or proxy. However, in an environment that includes proxies and servers, prior art encryption options may prove to be inadequate.
As the name implies, proxies operate on behalf of another computer, usually a client. When a client issues a request, the request is passed to the proxy and then the proxy makes the request as if the proxy were the client. The proxy directs any responses to the request back to the requesting client. Although proxy and client work in a cooperative fashion, this does not mean that the client is willing to share the details of a request with the proxy. For example, a client may access a server in order to execute various financial transactions such as trading stocks or paying bills. While the client is willing to supply the appropriate account numbers and corresponding credentials to the server, the client does not necessarily want the proxy to have this information.
To more fully appreciate the dilemma, imagine being in the position of needing to deposit a paycheck, but not having time to perform the task personally. One solution might be to ask a coworker to make the deposit for you. You give the coworker your paycheck, a deposit slip, and instructions to deposit the check in your account. The coworker goes to the bank, deposits the check, and brings you back the deposit receipt. In performing this task, the coworker has learned the amount of your paycheck, your bank account number, and possibly your account balance. Now, it is not that you do not trust your coworker, but you would have preferred to maintain that information confidential.
After a little more thought, you decide to put the paycheck in a container that can be opened only by you and the bank. You also include a sheet of instructions for the bank to (i) deposit your check, (ii) place the deposit receipt in the container, (iii) close the container, and (iv) give the container back to your coworker. The coworker brings you the container. By using the container, you have accomplished your task and kept the details of the transaction from being disclosed to your coworker.
Proxy servers implement an analogous feature called tunneling. In tunneling, the proxy receives an encrypted message from the client that is addressed to a server. Only the server and client are able to decrypt the message. Operating on behalf of the client, the proxy forwards the encrypted message to the server. Upon receipt, the server decrypts the message, performs the task described in the message, encrypts the results from having performed the task, and sends the encrypted results back to the proxy. The proxy recognizes that the results are intended for the client and forwards the encrypted results to the client, where they can be decrypted and acted upon if necessary. As in the coworker example, the client accomplishes the desired task without disclosing any confidential information to the proxy.
Taking the analogy one step further, suppose that you leave the container on your coworker's desk with instructions that the container be taken to the bank. You coworker is a nice person, but is unwilling to perform this favor for just anyone. As a result, the coworker calls you and verifies that you are in fact the person making the request. Once satisfied that you are who you say you are and that the container is from you, the coworker performs the task as requested. Similarly, proxy servers may require authentication before acting on the client's behalf.
The problem with proxy authentication as taught in the prior art is that, while tunneled communication between the client and server is encrypted, direct communication between the client and proxy is not. Therefore, an eavesdropper may intercept authentication credentials passed between the client and proxy. After obtaining proper authentication credentials, the eavesdropper may instruct the proxy to act on the eavesdropper's behalf, as if the eavesdropper were the client. Gaining proxy authentication credentials represents a significant security breach because the proxy unwittingly may allow the eavesdropper to gain further information through accessing other network resources available to the proxy.